帮我成交第一个 OPC 项目的 Hermes 落地全拆解

来源：htmlDecode("Anton Coding")

原文链接：https://mp.weixin.qq.com/s/p--PspT8OMYrnRTAzB-ELQ

---

上一篇《我用 Hermes 成交了第一个 OPC 项目》发出后，很多读者对这套 Agent 的真实落地细节感兴趣。
所以这篇我把这套方案完整的搭建方式、流程 skills、文档模板都拆解出来。
这套方案也不限于 Hermes Agent。你也可以迁移到 OpenClaw、Claude Code、Codex 里使用，关键是把 PM 岗位拆成固定流程、可调用 skills 和可复用文档模板。

先把 PM Agent 定义成一个岗位

PM Agent 是一个产品经理角色的 Agent，不是通用聊天助手。

它的身份定义很窄：

角色：产品经理
核心职责：需求对接 → 需求清单 → 报价 → 合同 → PRD
信仰：先理解，再定义。结构先于细节。优先级是 PM 最重要的决策。
边界：产出到文档为止，不越界写代码。

这个狭窄的边界是关键。如果一个 Agent 同时又是 PM 又是程序员，它会在写需求时忍不住跳到技术方案，反而失去了 PM 视角的独立性。
PM Agent 的工作严格遵循五个环节的顺序推进：

① 需求挖掘与追问
   ↕ 先拿业务背景，再做 6 维度推演 → 提问 → 闭环
    ↓
② 功能需求清单输出 ← 甲方确认，范围锁定
    ↓
③ 报价
    ↓
④ 合同起草
    ↓
⑤ PRD ← 合同签完后给开发

每份产出物生成后立即过红线检查，不改完不发出。

每一步都要对应 skill 和产出物

需求挖掘要先拿到业务上下文

这个环节不是一上来就追问客户，更不是把 6 个问题一次性抛出去。
它分两步走。
第一步，先了解业务场景。
先拿到项目背景、现有系统关系、关键数据从哪里来、流向哪里去。这些信息可以来自客户口头描述、已有文档、接口说明、历史系统截图，形式不重要，关键是先有上下文。
没有背景信息就开始追问，看起来很积极，本质上是在瞎问。客户自己也未必知道真实需求，PM Agent 要先把业务链路拼出来，再判断哪里缺口最大。
第二步，再做推演与追问。
拿到基础信息后，Agent 对每一个模糊需求做内部推演，从 6 个维度检查空白点： 维度 推演什么 Source（来源） 这个需求是确认要做的，还是随口说的？谁提的？ Flow（流向） 完整链路是什么？谁触发、谁处理、谁消费？反方向要不要走通？ Failure（失败） 什么情况下会坏？断了、超时、异常数据怎么办？ Dependency（依赖） 依赖哪些外部条件？有没有文档、测试账号、技术支持？ Boundary（边界） "做完"怎么定义？哪些明确不属于这个模块？ Validation（验收） 验收时看什么？怎样算通过？以哪个系统为准？

推演发现空白后，再把空白转成一个问题问客户。一次只问一个维度，客户回答后重新检查所有维度，直到闭环。

推演（内部思考）
  ↓
发现空白 → 转化为 1 个问题，向客户提问
  ↓
客户回答 → 更新推演，重新检查所有维度
  ↓
仍有空白 → 继续追问下一个维度
  ↓
全部闭环 → 路由到文档对应位置

涉及的 Skill： ● discovery-probing — 需求推演与追问循环 ● client-delivery — 核心工作流 skill，包含交付纪律
纪律： ● 先了解业务场景，再推理追问。没有背景信息直接问，就是瞎问。 ● 一次最多问一个维度，不要一次抛 6 个问题。 ● 客户回答后重新检查所有维度，再决定下一个问题。 ● 全部闭环才写入需求清单。未闭环的先放待确认表。 ● 客户不耐烦了就停。客户说"先出方案"时，把未闭环项写进待确认表。
产出物：

需求梳理笔记（内部，飞书文档）
├── 业务背景与系统关系（来自第一步信息收集）
├── 追问闭环的需求条目（来自推演-提问循环）
├── 数据流向（已确认）
├── 外部依赖清单（影响报价的前置条件）
└── 待确认事项列表（未闭环的维度）

功能需求清单用来锁定范围

这是最关键的环节。 功能需求清单是甲方唯一会确认的需求文档，后续所有报价、合同、开发都锚定它。
涉及的 Skill： ● client-delivery — 需求清单纪律模块

写作纪律（PM Agent 的核心训练数据，每次输出前自检）：

❌ 不自创需求          — "这个系统应该有个XX功能"不是需求
❌ 不写条件分支         — "如果A则B否则C"是解释，不是需求
❌ 不暴露技术系统名     — 对甲方说"我的会员"，不说内部或第三方平台名称
❌ 章节不重复           — 同一件事只在一个章节出现
❌ 不写解释             — 解释性背景不放进需求清单，需求清单里只写"做什么"
✅ 每条需求可追溯到甲方原话
✅ 不确定的放待确认表
✅ 只写"做什么"和"不做什么"

产出物模板——《功能需求清单》：

# [项目名称] 功能需求清单

一、系统对接

1.1 [甲方系统A] —— 模块说明
    1.1.1 [具体需求项描述]
    1.1.2 [具体需求项描述]
    1.1.3 [具体需求项描述]
1.2 [甲方系统B]
    1.2.1 [具体需求项描述]

二、[用户端名称 / 小程序端]

2.1 [功能模块A]
    2.1.1 用户可见的功能描述
    2.1.2 交互说明
2.2 [功能模块B]

三、后台管理（如有）

3.1 [管理功能A]
    3.1.1 管理员可操作的内容

四、待确认事项

序号	事项	甲方回复	备注
1	权益来源是自有系统还是外部系统？	—	影响系统对接工作量
2	资源状态是否同步到用户端展示？	—	影响开发范围

报价把范围翻译成商务语言

做什么： ● 基于已确认的需求清单估算工期和价格 ● 原模块价格不动，新增需求单独成行
涉及的 Skill： ● client-delivery — 报价纪律模块 ● xlsx-manipulation — Excel 生成
报价纪律： ● 原有模块价格不动（改价显得不专业） ● 联调测试不拆成独立收费行（写进模块描述里，如"含全流程联调测试"） ● 只给总工期范围，不给模块工期分解 ● 不含项只写甲方提过但本期不做的内容——不凭空添加双方从未讨论的排除项

产出物模板——报价单：

# [项目名称] 项目报价单

一、项目概述

一句话说明项目背景和性质。

二、报价明细

功能模块	主要内容	报价（元）
模块A	含全流程联调测试	¥X,XXX
模块B	含全流程联调测试	¥X,XXX
合计	总工期：X-X 个工作日	¥XX,XXX

三、不含（范围边界）

只写甲方明确提过但本期不做的内容。

四、开工前置条件

甲方需提供的：接口文档、账号权限、设计图等

五、交付标准

功能清单所列功能全部实现并上线。

六、开发周期

本合同签订并收到预付款之日起 X-X 个工作日。

七、付款方式

- 预付款：XX%（合同签订后 X 日内支付）
- 尾款：XX%（项目验收通过后 X 日内支付）

合同只承接已经确认的范围

做什么： ● 报价确认后，起草正式委托开发合同 ● 生成 docx 文件，填空线供双方填写
涉及的 Skill： ● docx-manipulation — python-docx 生成 Word 文档 ● client-delivery — 合同起草指南
合同结构模板——委托开发合同（简化版）：

委托开发合同

甲方（委托方）：[公司全称]
法定代表人：[姓名]
联系电话：[电话]

乙方（受托方）：[个体户全称/个人]
经营者/法定代表人：[姓名]
联系电话：[电话]

鉴于甲方有意委托乙方开发 [项目名称]，双方经协商一致，签订本合同。

第一条 项目范围
以《功能需求清单》为准。超出清单范围的双方另行签订补充协议。

第二条 交付物
可运行源代码 + 部署文档 + 功能验收。

第三条 开发周期
自甲方提供完全部所需资料之日起 X-X 个工作日。
甲方逾期提供资料的，开发周期相应顺延。

第四条 费用与付款
合同总金额：人民币 [大写] 元整（¥[小写]）。
1. 预付款：合同签订后 X 日内支付总金额的 XX%。
2. 尾款：项目验收通过后 X 日内支付剩余 XX%。
3. 乙方收款账户信息另行书面提供。

第五条 验收标准
1. 验收依据：《功能需求清单》。
2. 甲方应在乙方提交验收通知后 X 个工作日内完成验收。
3. 逾期未反馈视为验收通过。

第六条 知识产权
甲方付清全部款项后，本项目定制开发的源代码知识产权归甲方所有。
乙方原有的通用技术、工具库不受本条限制。

第七条 保密
双方互负保密义务，合同终止后 2 年内继续有效。

第八条 售后服务
自验收通过之日起，乙方提供 X 天免费故障修复服务。
新增需求或功能变更，双方另行协商报价。

第九条 违约责任
1. 乙方延期交付：每逾期一日按合同总额的 1‰支付违约金，上限 10%。
2. 甲方逾期付款：每逾期一日按应付金额的 1‰支付违约金。

第十条 合同终止
双方协商一致可解除合同。一方严重违约的，另一方有权解除。
合同解除时，已完成的开发成果按实际工作量结算。

第十一条 争议解决
协商不成的，提交甲方所在地人民法院诉讼解决。

本合同一式两份，双方各执一份，具有同等法律效力。

甲方（盖章）：               乙方（盖章/签字）：
日期：                       日期：

填写说明： ● 金额用大写为主小写为辅，如：人民币 [大写金额]（¥[小写金额]） ● 合同编号非必须，小项目可删掉 ● 乙方若为个体户，税务定性为经营所得（税负低于个人劳务报酬） ● 合同用 docx 直接上传云盘，不要转为在线文档——甲方要下载填写

PRD 留到合同之后再写

做什么： ● 合同签完后输出给开发的结构化需求文档 ● 每条功能转为用户故事 + 验收标准
涉及的 Skill： ● prd-development — PRD 模板框架 ● user-story — Mike Cohn 格式 + Gherkin 验收条件 ● epic-breakdown-advisor — 大模块拆细
产出物模板——PRD：

# [项目名称] PRD

1. 项目背景

- 为什么要做这个项目？
- 解决什么问题？

2. 用户画像

- 谁用这个系统？（终端用户类型、角色）

3. 功能结构

- 按模块列出所有功能点
- 每个功能点标注优先级：P0 / P1 / P2

4. 用户故事

模块A：[模块名称]

Story A1：[用户故事标题]
As a [用户角色]
I want to [功能描述]
So that [业务价值]

Acceptance Criteria：
- [ ] 前置条件：[当 xx 状态时]
- [ ] 操作步骤：[用户点击 xx → 系统展示 xx]
- [ ] 预期结果：[xx 应该正常展示/跳转/保存]
- [ ] 异常处理：[网络异常/数据为空时怎么办]

Story A2：...

模块B：...

5. 数据流向

- 系统架构图（如有）
- 数据流转路径（A → B → C）

6. 约束与边界

- 技术约束（框架、版本、部署环境）
- 本期不做的功能清单

7. 风险与待确认

- 已知风险
- 待技术验证的事项

一个完整的用户故事示例：

Story：终端查询用户权益
As a 终端操作员
I want to 在服务过程中输入用户手机号查询权益余额
So that 我可以根据用户权益完成本次服务

Acceptance Criteria：
- [ ] 前置条件：终端系统已联网，用户已注册
- [ ] 输入手机号后点击查询 → 系统展示：用户姓名、可用权益余额
- [ ] 如手机号未注册 → 提示"该手机号未注册"
- [ ] 如网络异常 → 提示"网络异常，请重试"
- [ ] 查询响应时间 < 2 秒

每份文档发出前都要过红线检查

每份产出物生成后，PM Agent 自动跑 document-audit，不过不改不发。
红线检查清单： 类别 检查项 内部执行细节 是否暴露了“单兵作战”、“一个人做” 定价逻辑 是否出现了“日薪”、“buffer”、“实际只要 X 天” 自创范围 是否写了甲方没提过的功能或排除项 专业措辞 是否用了“经 API 调研发现”（应改为“深入分析后”） 报价单结构 原价是否变动、联调测试是否单独收费 文档引用 是否把 PRD 等内部文档引用到甲方可见的文档里

对外公开分享文章另有独立的脱敏校验（ publication-sanitize ），检查真实客户名、真实金额、个人信息等，两套标准不混用。

Skill 架构不要写成一个大 prompt

PM Agent 的行为方式不来自一个巨大的 prompt，而是来自一组分工明确的 skill： Skill 用途 来源 client-delivery 甲方交付完整工作流 + 全部纪律 ✅ 亲手搭建 document-audit 交付文档红线检查清单 ✅ 亲手搭建 prd-development PRD 模板框架 内置，按需调用 user-story 用户故事格式化 + Gherkin 验收条件 内置，按需调用 docx-manipulation 合同等 Word 文档生成 内置，按需调用 xlsx-manipulation 报价单 Excel 生成 内置，按需调用
设计原则： skill 是通用的、可复用的，不包含任何具体客户名、项目名、金额数字。

最终产出物要按受众分层

环节 产出物 受众 格式 ① 需求对接 需求梳理笔记 内部 飞书文档 ② 需求清单 《功能需求清单》 甲方 飞书文档 ③ 报价 报价单 甲方 飞书文档 + Excel ④ 合同 《委托开发合同》 双方 docx ⑤ PRD PRD 开发团队 飞书文档
每份产出物生成时自动过 document-audit ，红线清零才交付。

搭 PM Agent 先固定流程纪律

几点经验： 1 角色边界要窄。 PM Agent 就做 PM 的事，不写代码、不部署服务器。边界清晰 Agent 才能稳定。 2 纪律比模板更重要。 模板谁都能写，但"不自创需求""不暴露日薪""不在需求清单里写解释"这类纪律是踩坑踩出来的，它们才是 PM Agent 真正的护城河。 3 每一份产出都过红线检查。 不是最后才验收——文档刚生成时就跑一遍。错了就改，改了再发。特别要注意：真实客户名称、真实金额数字不能出现在分享文章中。 4 Skill 不要绑定具体项目。 任何项目名、客户名、专属格式都不能写进 skill。skill 应该是通用能力，拿给任何甲方都能用。 5 流程顺序不能乱。 需求没确认不出报价、报价没确认不出合同、合同没签完不出 PRD。Agent 需要严格的流程编排才能替你把好关。

从这篇文章开始，搭你自己的 PM Agent

如果你也想搭建自己的 PM Agent，可以先不用追求复杂。先把这五个阶段固定下来：

需求对接 → 功能需求清单 → 报价 → 合同 → PRD
再给每个阶段配上对应的 skill、模板和红线检查。
真正能帮一个人接项目的 Agent，不是回答更像人，而是能进入真实项目的关键节点，稳定产出能被客户、合同和开发团队使用的东西。
下一步做什么： 1 在 Hermes/OpenClaw 里创建一个新 profile 2 装上 client-delivery 和 discovery-probing 这两个 skill 3 把 SOUL.md 的 PM 角色定义（角色、核心职责、信仰、边界）写进去 4 拿一个真实客户的需求，跑一遍第一步的 6 维度推演 5 产出需求梳理笔记，看看闭环了几个维度，还有几个挂了待确认

先跑通第一个环节，再逐步补全后续流程。Agent 是一步步长出来的，不是一次写完的。